home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000018_timbl _Thu Nov 28 11:32:02 1991.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <timbl>
  2. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA16716; Thu, 28 Nov 91 11:32:02 GMT+0100
  4. Date: Thu, 28 Nov 91 11:32:02 GMT+0100
  5. From: timbl (Tim Berners-Lee)
  6. Message-Id: <9111281032.AA16716@ nxoc01.cern.ch >
  7. Received: by NeXT Mailer (1.62)
  8. To: www-talk@nxoc01.cern.ch
  9. Subject: misc. architecture notes
  10.  
  11.  
  12.  
  13. Begin forwarded message:
  14.  
  15. To: timbl@nxoc01.cern.ch
  16. Subject: misc. architecture notes
  17. Date: Wed, 27 Nov 91 15:06:02 CST
  18. From: connolly@pixel.convex.com
  19.  
  20. [Any minute now, my ride to Kansas City for the holidy
  21.  will arrive. In the mean time, here are some ideas.]
  22.  
  23. WAIS
  24.  
  25. It's beginning to look like you should try to fit WWW inside
  26. WAIS, rather than the other way around. You need to talk with
  27. those guys about format negotiation and document representation,
  28. and both groups need to combine WAIS docid's and WWW anchor
  29. addresses.
  30.  
  31. In other words, I think the WWW browser should be a WAIS client.
  32. But come to think of it, there's no reason a browser can't be a WAIS
  33. client, a HTTP client, an FTP client, and an ARCHIE client all at
  34. the same time.
  35.  
  36. For example, I used to compile WWW support into my browser. Lately,
  37. I changed my mind. Now I compile a separate programe that supports
  38. WWW access. I invoke
  39.     htaccess HTML_ADDRESS
  40. and the stdout of that process is the HTML content of the node.
  41. I pipe that through html2rtf.pl, and display the output. The user clicks
  42. on anchors, and the whole process repeats.
  43.  
  44. I could, however, use waisq, or an archie client, or an nntp client, or
  45. an ftp client in place of htaccess, write a few more foo2rtf converters,
  46. and support all this stuff. Hmmm... lots to think about.
  47.  
  48. TEXT OBJECT
  49.  
  50. I've been reading some of the design notes in your web, and I
  51. was particularly interested in your ideas for a portable text
  52. object. My software uses many of these concepts. I gave up
  53. editing capabilities to simplify the design and make it doable
  54. in two months.
  55.  
  56. I think you would be crazy to try to do the text object without C++.
  57. Perhaps you could provide a C interface and a sample implementation
  58. in C that doesn't have all the features. But for WYSIWYG displays,
  59. the problem is just too complex to maintain in C.
  60.  
  61. You should take a close look at TMLib. Some of the implementation
  62. needs rework, but the architecture fits your needs pretty well.
  63. I'm not using any of that code, but I'm using lots of their ideas,
  64. e.g. the model-format-view architecture.
  65.  
  66. HTML
  67.  
  68. You need a DTD. Have you seen the SGMLS tools? They parse SGML and
  69. write a line-oriented representation as output. This would be ideal
  70. for format negociation. You could support plaintext and cerainly RTF,
  71. and probably make stabs at TROFF, TeX, and perhaps PostScript.
  72.  
  73. Have you considered how to embed links in other formats? Please let
  74. me know how you decide to do it in RTF. My idea is to translate:
  75.     <A HREF=foo>text</A>
  76.         to
  77.     {\field{\fldinst HREF=foo}{\fldrslt text}}
  78. [for implementation reasons, I'm currently putting the \fldinst group
  79.  after the \fldrslt group, but that's a minor detail.]
  80.  
  81. The resulting files still work when loaded into MS Word, though if you
  82. saved them again I doubt the HREF would still be there.
  83.  
  84. [my ride is here. more later]
  85.  
  86. Dan
  87.  
  88.